Networks connect many computers together allowing them to exchange data via communications lines. Several standards defining how such data exchanges should occur have been developed and implemented to ensure that computers and computer programs use the same protocols can successfully exchange data. One of the problems associated with the ability to exchange data is ensuring that a requestor entity, such as a user on a network is authorized to access data in a server entity, such as another computer.
Firewalls are devices, such as programs or separate computer systems which were introduced in order to address the security problems associated with connecting a once private network such as a local area network connecting computers in an office, to an "Internet", where the data transmissions are open to eavesdropping, and the potential exists for "hostile" outsiders to disrupt network service or tamper with or attack systems residing on the private network.
There are a number of different classes of firewalls, each designed to address different types of security concerns. In spite of the different approaches, all firewalls perform a function known as "relaying", where Protocol Data Units (PDUs) are received by the firewall from a sending application entity and forwarded to a receiving application entity, possibly with some modifications to the original PDU. Since firewalls are designed to enforce a security policy, some information, or context, must be extracted from the PDUs and subjected to a set of rules. Based on the outcome of the rules check, the firewall performs an action; the PDU is either relayed, modified and relayed, or rejected in some fashion. The precise action is chosen by the designer of the firewall in order to affect the behavior of the system such that the security policy is satisfied. The action is of course subject to the constraints of the protocol the firewall is designed to support.
One suite of protocols used by application entities to exchange data is called Open Systems Interconnect (OSI). OSI Applications are built on the notion of a 7 layer model. Starting at the top, layer 7 is referred to as the application layer, layer 6 is the presentation layer, 5 is session, 4 is transport, 3 is network, 2 is data link and 1 is physical. Starting at the bottom and working up, the physical layer handles the transmission of bits over a communications medium such as a telephone line. The data link layer collects the bits into a group of bits called a frame. The network layer routes the frames between nodes in the network, but calls the frames packets of data. These three lower layers are implemented by communication devices, including switches in the network. The transport layer treats the packets as messages and is the bottom layer in a computer. It interfaces between the internal routing or session layer in the computer and the network. The session layer provides the glue that ties together different data streams, such as the audio and video portions of a teleconferencing application. The next layer up is the presentation layer which deals with the format of data exchanged. Finally, the application layer is the topmost layer and in terms of the Internet, may be thought of as including File Transfer Protocol (FTP) one of the mechanisms used to exchange data in file format on the Internet.
Each layer N provides services to the layer above it (layer N+1) and requires services of the layer below (N-1). Firewalls typically operate as a protocol peer at a particular layer (e.g. the transport layer, N=4), and will forward or relay the protocol information and data (PDUs) at that layer. A layer-4 relay operating over the Internet protocol suite would operate at the Transaction Control Protocol (TCP) protocol layer and forward TCP segments (application data) between communicating application entities, and is considered a protocol peer at the TCP layer.
For applications designed to run on the Internet suite, the application layer is layer 7 when mapped to the OSI model, with layers 5 and 6 being implicitly provided by the TCP. Thus Internet firewalls can perform application specific security checks by simply monitoring the PDUs carried by the transport layer. If a security violation is detected, a meaningful application specific protocol response can be created from context information captured during the session. Internet firewalls respond to security violations by fabricating a response at layer N or N+1, where N is the layer at which the firewall acts as a peer (relay). For example, an FTP firewall acting as a layer-4 relay may reject a connection attempt from an unwanted client by performing a TCP close (layer 4 action), or may reject an attempt to PUT, or store a file by generating a FTP error response (layer 7 action). Note that the layers 5 and 6 actions are implicitly provided by the TCP.
Since Internet application protocols tend to be text based, the data capture and response mechanism can be constructed from relatively simple parsers and encoders, and do not require large amounts of state information to be maintained. Internet firewalls can identify the application context by examining the destination TCP port number that the client Internet application attempts to connect to. An Internet firewalls need not examine any application layer PDUs to determine the type of service being requested. E.g. an Internet firewall can distinguish between a request for Simple Mail Transfer Protocol (SMTP) service for email from that of FTP based on port number only. Thus, an Internet firewall can be configured to allow SMTP but deny FTP simply by accepting requests destined to the SMTP port but denying requests to the FTP port.
For OSI applications, the configuration is more complex. OSI applications are expected to conform strictly to the 7 Layer model (no implicit layers), and make use of the OSI session and presentation layers. Each of these layers introduce extra states into the session, and they operate as protocol entities in their own right. A failure at a higher layer must be conveyed via and onto services provided lower layers.
During a connection establishment phase, the transport layer, session layer, and presentation layer will all attempt to form an association with their corresponding protocol peer, and will negotiate session parameters. The application layer is actually made up of several Application Service Elements (ASEs), each providing support for a different set of related services and protocols, and they can be arranged to form "sub-layers" of the application layer. Common ASEs include the Association Control Service Element (ACSE) and the Remote Operations Service Element (ROSE), and are the core elements found in most OSI applications. ACSE is used to form and tear down associations (connections) and ROSE is used to convey requests and in a uniform fashion. Identifying user credentials and authentication information are exchanged on the protocol chosen (X.500, X.400 or FTAM to name a few), such as the user's Distinguished Name and a password or cryptographic signature. The process of forming an OSI application layer association is known as binding.
Once an application is bound to its protocol peer, the application is said to be in session and processing enters a steady state where application layer PDUs are exchanged and processed until one of the application peers initiates the closing of the session. An orderly release of the association is called unbinding.
All OSI application PDUs are transmitted as binary. Application and presentation layers are typically encoded in a binary format called ASN.1; the session and transport layers fragment the information.
OSI applications are designed to operate in an environment where the OSI Transport layer is employed. A method was developed to map OSI transport services to the Internet stack. This method is described in Internet Request For Comment-RFC-1006 which is stored on many servers on the Internet under a file named rfc1006.txt. In the RFC-1006 method, the OSI Transport Class 0 (TP0) is selected, and TP0 PDUs (T-PDU) are encapsulated with a short four octet header called a T-Packet (TPKT). The RFC suggests that servers which implement this method respond to TCP port 102 which has been reserved for OSI over TCP, but the actual port chosen is left to an administrator or implementor's discretion.
An IP transparent relay would listen on both wires for specific IP data frames to be sent. The IP transparent bridge would contain a list of network addresses associated with each wire so that when one of these frames is received a list is examined and the IP bridge would `grab` it and put it on the other network. The problem with this simple IP transparent bridge solution is that it can only `filter` information based on the IP addresses contained within the data. IP address spoofing is very easy, therefore this solution alone is not secure enough for the needs of securing an OSI application.
The transparent relay functionality must be moved up higher again, this time to the OSI Transport layer service. The transport layer over IP is TCP. A TCP transparent relay solution would look for data on specific TCP ports. The TCP bridge would filter based on a specific TCP port which generally maps to a unique application. The problem however, is that the OSI applications are not required to operate on any specific TCP port. Therefore the solution must further examine the data being passed to ensure it matches the content expected of an application communicating through it. But to verify that data, the TCP bridge itself must reply to the connection request. Once the reply is received, the originator would begin sending application data to the TCP bridge. The TCP bridge would then examine the data and decide if it matches the form expected for this application. If it does, the TCP bridge would establish an independent session with the "real" destination device and pass the senders data on to it. Adding this additional processing to accept a connection request and further examine the data takes the functionality beyond a simple transparent bridge. Generally this complete combination of functionality is what is termed a "proxy" solution.
Internet firewalls approach the question of how to securely provide support for OSI protocols using two major approaches, application gateways or proxies. Application gateways are a special form of firewall where the firewall accepts and processes PDUs at the application layer, and appears on the network as a protocol peer to both the client and the server. For OSI protocols, all seven layers are processed by the application gateway, and separate application layer associations are maintained between the firewall and the client, and between the firewall and the server. Thus the firewall is said to be "visible" to the client and the server since it is a directly addressed application entity; the client application thus needs to be aware of how to address the firewall in order to contact the server.
Application gateways are able to glean the full context of the information being processed by virtue of it's operating at the highest layer, giving it a distinct advantage over traditional N-layer proxies (discussed below) when attempting to enforce a protocol specific security policy.
For the Internet applications, application gateways provide the most security, and are feasible to implement due to the simplicity of the protocols. However, OSI protocols are very complex, involving several layers above the TCP layer. Also, since the gateway is a protocol peer, it must support all the necessary protocol elements required to be an actual server for that application.
Because of the complexity of the required service elements and the upper layers of the OSI stack, application layer gateways for OSI services tend to be implementations of the application server themselves sometimes with limited functionality. For example, an application gateway for one communication protocol published by the International Telecommunication Union called X.500 usually takes the form of a X.500 Directory System Agent (DSA), which is the server component of X.500. The DSA is modified to support the security policy decisions in support of the firewall functionality.
While this arrangement offers the potential for very good security, performance is an issue because the firewall must implement or simulate the functionality of the server, often involving complex calculations, data manipulation and a fair amount of saved state information. The firewall may have to buffer large amounts of data before being able to relay the data to the other independent application association. The complexity of this solution also makes it very difficult to prove the correctness of the implementation and to analyze the resulting implementation for security flaws and vulnerabilities.
The second major approach involves filtering N-layer relays (proxies) An N-layer relay acts as a bridge which picks up PDUs sent on one network and retransmits them onto a different network. These devices are called "transparent" because neither end station application entity is aware of the relay.
In order to be termed a proxy, an N-layer relay must perform a firewall function in support of a security policy. Proxies always operate below the application layer, and filter PDUs based on attributes visible at that layer.
If a proxy were to operate at a data link layer, referred to as a MAC layer, it would capture Ethernet frames and examine the addresses in the MAC header, and filter the payload portion (IP datagrams) to determine Internet Protocol (IP) addresses. Higher layer filtering would be infeasible because data would have to be buffered and reassembled in order to gain enough context, and the semantics of TCP are such that only limited number of frames could be buffered and examined before it would become necessary to send them in order to receive more. So if only a partial security context has been determined when the buffer threshold was reached, the data would have to either be discarded or sent without full validation--in either case, an unacceptable alternative for OSI application.
IP layer proxies have essentially the same characteristics as the MAC proxy in terms of policy and limitations. IP proxies gather IP datagrams and can filter on the IP, header, and usually filter on the TCP header as well. IP proxy firewall behavior is available in most modern commercial routers.
TCP proxies can filter on IP addresses, TCP port numbers and other attributes visible at the TCP layer, and relay TCP segments from one network to the other. TCP proxies can be fitted with protocol specific filtering and appear "in-situ", with application data being examined and relayed in real time with only limited buffering, in contrast with the application gateway which would collect a full application context before relaying the data. Most firewalls use the term proxy to refer to a TCP layer relay. A TCP proxy maintains separate TCP connections between the client and the firewall, and between the firewall and the server. In order to satisfy the transparency requirements, a TCP proxy must be capable of accepting a connection attempt from the client on behalf the server.